1. Field of the Invention
The present invention generally relates to data processing systems. More particularly, the present invention pertains to methods and systems for managing storage devices associated with data processing systems.
2. Description of the Related Art
Modern data processing systems such as personal computers are often used in association with other systems for various purposes. They are sometimes connected to a network such as a LAN (local area network) or a WAN (wide area network) such as the Internet, where many other data processing systems are connected. In some cases, a small number of data processing systems are also interconnected to each other, either directly or indirectly, often to achieve certain goals. Connected systems provide many benefits. For example, certain peripheral devices on one system can be shared with other systems that are connected to the system in some way. Other resources can also be shared among the data processing systems that are interconnected to each other.
Smaller data processing systems or devices such as personal digital assistants (PDA) or portable digital media players are often operated in connection with bigger or more powerful data processing systems such as personal computers for certain tasks. Portable data processing devices tend to have less computational power such as processing power or memory and less resource such as non-volatile storages. They also tend to have smaller display screens and smaller input panels, and hence they are generally less usable than their bigger counterparts. These data processing devices are sometimes connected to another data processing system, e.g., a host computer, to provide additional services to the host system. For example, a mass storage device of a laptop computer can be “mounted” to the host computer, thereby allowing the host to directly access the data on the laptop. Data processing devices are also operated in connection with host computers to enhance their functionalities and/or usabilities. For example, the devices that are not directly connected to a network may exchange or update data through a host system. Data such as personal information stored in a data processing device may be “synchronized” with the data in another data processing system by connecting, or “docking”, the device to the system and performing an update operation. Many commercial PDAs come with the “sync” software. Digital media players, such as iPod of Apple Computer, Inc. of Cupertino, Calif., are also often used with a host computer to download and/or upload digital media content. For example, in the case of iPod and other portable music and video players, the iTunes software is used for this purpose. iTunes can also be used to sync the digital media list and other information including personal address books or calendars.
Many media players or other (portable or non-portable) data processing devices equipped with non-volatile memories such as hard disks or flash memories can be used as extra storage devices when they are docked to a host data processing system to expand the storage capacity of the host. This is accomplished, for example, by connecting or docking the portable device or computer to the host system such as a personal computer via a small computer system interface (SCSI) bus and placing the portable device into SCSI target mode. SCSI target mode is a mode in which a device accepts and implements SCSI commands, e.g., as if it was a peripheral device connected to the SCSI bus. The host system can typically access the storage device of the portable device as if it was locally connected, and, in particular, it can access the blocks of the storage device. This is often called SCSI target mode, or target disk mode (TDM) in the prior art. In the target disk mode, the docked device loses its autonomy and provides only the functions of transmitting SCSI commands between the host and the storage device.
This is illustrated in FIG. 1. In FIG. 1A, two different modes are shown in which a device might be operated in connection with a host. The device may be docked 104 in a host 110 and function as a storage device to the host, or it may be operated independently or autonomously 102. In this disclosure, the docked mode may be called a disk mode, to emphasize the resource sharing aspect of the docked state, and the undocked and autonomous state may be referred to as a device mode. The device and the host are relative terms, as used in this disclosure, and they do not indicate that one data processing system is inherently different from another data processing system. For example, as disclosed later, a laptop computer may act as a host whereas a desktop computer may be connected to the laptop in a disk mode. Typically, connecting a device to a host, as indicated by arrow 106, triggers the device to change its state to the disk mode 104. However, in some cases, explicit mode switching may be needed, either at a hardware level or at a software level. Likewise, disconnecting or undocking the device from the host, as indicated by arrow 108, typically changes the device's mode into the device mode 102. This is further illustrated in FIG. 1B as a flow chart. A device initially in an autonomous or device mode is connected to a host computer at 112. The connection then puts the device now in a disk mode, as indicated in a block 114. In this state, certain resources such as hard disks of the device may be shared with the host. At 116, the device is disconnected from the host. The device can be disconnected through a command in a user interface. Then, as indicated in block 118, the device is back in the autonomous operational state, that is, the device mode. As stated earlier, the mode switching between the two modes can be triggered either explicitly or implicitly.
In a SCSI emulation device, for example, the device or target system receives standard SCSI commands from the host, or the initiator system in the SCSI jargon, and emulates the SCSI device being accessed. The target device thereby provides a practical and economic system for achieving access to a multiplicity of peripherals in a SCSI environment. The initiator sends standard SCSI I/O device driver commands. The target system uses its own Basic Input/Output System (BIOS) and device drivers to access the non-local device and perform the initiator command. Thus, the initiator uses standard I/O device drivers for the given device and the target uses emulation code with redirection and/or translation routines to look like a standard SCSI device. The initiator system accesses the non-local devices on another computer as if it were local to their own computer. The user has the benefit of not needing to learn and remember additional commands to access devices on the other computers. In fact, the standard device drivers are typically used on the host system as if the peripheral units were integral with the basic system. As stated earlier, however, the target system loses its autonomy as a data processing system once it is put into a docked mode, or a disk mode. This is partly by design, for example, to maintain the integrity of the storage medium. When multiple systems, e.g., the host and the portable systems, have control over a storage device, the integrity of the data on the storage medium may not be guaranteed.
FIG. 2 illustrates a target system in an undocked state (or, a device mode) in a block diagram form. The initiator or the host system is not shown in the figure. The system as illustrated in the figure comprises, among other things, a main processing module 132 and a mass storage device 138. The mass storage device may be “internal” or “external” to the main or host device. The main module and the storage device are typically connected to each other, as indicated by the arrow in the figure, through a standard communication bus such as SCSI (small computer system interface), ATA or SATA or IDE (integrated drive electronic), USB (universal serial bus), or firewire (IEEE 1394). The device or system typically includes a file system 134 and a device driver 136. Device driver 136 is responsible for low-level communication between the main processing module 132 and peripheral devices such as the storage device 138. As schematically shown in the figure, the file system 134, which provides high-level service to the system or application level softwares, typically relies on the device driver 136 for low-level tasks. In cases of a block storage device, the device driver is often responsible for the block level management of the storage device.
This exemplary system is further illustrated in FIG. 3 as a block diagram. In particular, the system 154 corresponds to the system shown in FIG. 2. In the example of FIG. 3, the device 160 with a mass storage device 168 is currently docked to a host computer 152. That is, the system (or, “target device”) is in a disk mode. In this mode, the mass storage device associated with the docked device may be managed by the host as stated earlier. The host data processing system 152 shown in the figure includes a file system software 156 and a device driver 158 as is typical of many such systems. The target device 154 is depicted with two separate units as in FIG. 2 for convenience: The peripheral device, namely the mass storage device 168 and the rest 160. As stated earlier, the mass storage device 168 of FIG. 3 may be internal or external and it is connected to the main processing system 160 through a communication bus. The system 160 again includes a file system 164 and a device driver 166, and the device driver 166 is responsible for the low-level communication with the mass storage device 168. The target system 154 also includes a special hardware or software 162 responsible for communicating with a host or initiator computer, the host 152 in the figure. In some cases, the unit 162 includes a communication port (“C.P.”) and/or a control program (“C.P.”). When the target device 154 is docked to the host 152, the host computer may access the data in the mass storage 168 through the connection on the communication port 162. As illustrated in the figure, the host system does this through a device driver 158 as if the mass storage device were connected locally. As stated earlier, once the target device 154 is in a disk mode and the host system 152 has access to the mass storage 168, the target device loses autonomy, This is partly to protect the data integrity of the storage. In many applications involving this type of setup, the target device is generally simple data processing systems and they typically use DOS FAT (disk operating system file allocation table) file system. The FAT file system lacks sophistication to allow multiple system access. Therefore, in a typical system setup, once the target system is in a disk mode, it only relays the data access command from the host to the mass storage. For example, a file access command initiated by an application on the host computer 152 may be relayed through the host's file system 156, the device driver 158, and the control program 162, the target system's device driver 166, and finally to the target's mass storage device 168. The response from the storage device may be returned in the opposite way.
This is schematically illustrated in FIG. 4A as a simple sequence diagram. The diagram includes three actors, Host Computer 182, Target System 184, and Mass Storage 186, which is coupled to the target system 184, either directly or indirectly. The target system or device 184 is docked to the host computer 184. As illustrated in the diagram, the host first sends the data access command to the target device, at 188. The command is then relayed, either with or without modification, to the storage device 186, as indicated by the arrow 190. Next, the processed data is returned to the target device, at 192, which is in turn relayed to the host as indicated by the arrow 194. As illustrated in this simplified process, in the disk mode, the target device loses its autonomy and only plays the role of virtual device driver or communication link.
This is further illustrated in FIG. 4B as a flow chart. The chart illustrates an exemplary process similar to the one shown in the sequence diagram of FIG. 4A. In the exemplary process shown in FIG. 4B, a host computer accesses data in a storage device through a data processing system (or, “target device”) managing the storage device. The process begins by connecting or docking a target device to a host computer, at 212. The target device includes a hard disk. Once it is connected to the host, it enters the disk mode (or, target mode or target disk mode) as indicated in block 214. As stated early, mode switching may require explicit operations in some cases. The host computer then sends a data access request, at 216. The data access request might include requests for reading data from certain blocks of the storage device or for writing data to certain blocks. The target device relays the request to the hard disk, at 218. Once the request is fulfilled by the hard disk, at 220, the response such as the requested blocks of data is returned to the host computer through the target device as indicated in block 222.
As stated in the beginning, data processing systems may be alternatively connected to each other through networks such as a local area network (LAN) instead of being connected directly. This solution poses a number of difficulties for the user, however. A LAN approach requires significant hardware and software investment and necessitates extensive system overhead. A network requires one network adapter per computer. An abundance of software is needed to implement the communication protocol and handle device sharing. In some cases, for example, special types of file systems need to be used for the hard disk to be shared. Furthermore, Local Area Networks require the user to learn a new menu of commands. This is extra work for the end user and often adds significant delay in accessing the peripherals. Therefore, a LAN approach is generally suitable for wide-scale resource sharing such as in network storage systems.
FIG. 5A illustrates one such method called NAS (network attached storage) in the prior art. Two data processing systems 242 and 244 are connected through a network such as LAN, as indicated by arrow 260 in the figure. The computer B, 244, manages a mass storage device 258, through a file system 254 and a device driver 256. The computer A, 242, also has a file system and 248 and a device driver 250, and it may have local storage devices of its own (not shown in the figure). Both computers have network interfaces 246 and 252 for communication and other network related infrastructures, e.g., hardwares and/or softwares (not explicitly shown in the figure). The computer A 242 accesses the data in the mass storage device 258 through the computer B 244. The computer B “translates” data access request from the computer A and acts as a proxy. The response from the mass storage device is similarly translated and returned to the computer A through the network 260. This is further illustrated in FIG. 5B, which shows an exemplary process of managing and accessing (e.g., reading/writing) data on a mass storage device from a remote host as a flow diagram. The process begins by connecting two computers through a network, at 272. One of the computers has a storage device that can be shared. The “remote” computer then sends a data access request through the network, at 274. The data access request may be a request to write a file on the storage device. In network attached storage systems, the data access is typically done at a file level. Next, the “local” computer processes the file access request, at 276 and 278, and sends the response including the requested data, if any, back to the first computer, as indicated in blocks 280 and 282.
FIG. 6A shows another prior art system called storage area network (SAN) in a block diagram form. A mass storage device 320 is shared by multiple computers connected on the network (indicated by arrows in the figure). The diagram shows two computers, 302 and 304, each of which is equipped with file systems, 308 and 314, and device drivers, 310 and 316, respectively. The support for networking is also schematically illustrated by network interfaces 306 and 312 in the figure. In a storage area network system, the data at the mass storage device can be accessed at a block level, and therefore it typically includes a special system to coordinate data access by multiple computers. This is indicated in the figure as a lock manager 318. The data access from a computer on the network, such as 302 or 304, involves locking of necessary blocks in the mass storage 320 to maintain the integrity of the data in the storage system. FIG. 6B illustrates this as a flow diagram. At block 342, a computer A sends a request to access a certain block on a shared storage device. This prompts a lock manager to lock the pertinent blocks, at 344, so that the block cannot be concurrently accessed by another system. Once the request is completed, at 346, the lock manager unlocks the blocks, at 348, and other systems on the network can access, e.g., read or write, data on the blocks.
Another relevant system called logical volume management (LVM) is shown in FIG. 7A. The figure shows two storage devices 392 and 394. Each storage device may have one or more partitions. In a logical volume management system, storage devices are typically managed at a partition level. In this scheme, one or more partitions in block storage devices are grouped into logical volumes, as indicated by a block 390 in the figure. A host system 382, which has a file system 384 and a device driver 388, then accesses the data in the storage systems 392 and 394 through this virtual layer 390. In some implementations, a special purpose program 386, typically called logical volume manager, provides certain necessary functions. In the figure, the LVM 386 is drawn between the file system 384 and the device driver 388. FIG. 7B depicts an exemplary process of logical volume management. In particular, it illustrates a process for automatically resizing a volume. The exemplary process starts from a file system initiating a file write request to a particular logical volume, at 422. The exemplary scenario then assumes that the particular logical volume does not have enough free space to fulfill the request, as indicated in block 424. In such a case, the logical volume manager increases the volume size, at 426. This is typically accomplished without changing the low-level partitions with the help of the additional logical volume layer built on top of the device level partitions. Then the request is honored, at 428, and the response is returned to the host's file system, at 430.